home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000049_owner-urn-ietf _Wed Oct 16 17:58:44 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21492 for urn-ietf-out; Wed, 16 Oct 1996 17:58:44 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21487 for <urn-ietf@services.bunyip.com>; Wed, 16 Oct 1996 17:58:42 -0400
  3. Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA18868  (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 17:58:39 -0400
  5. Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id QAA08668; Wed, 16 Oct 1996 16:54:11 -0500 (CDT)
  6. Date: Wed, 16 Oct 1996 16:54:11 -0500 (CDT)
  7. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  8. Message-Id: <199610162154.QAA08668@ncsa.uiuc.edu>
  9. To: Larry Masinter <masinter@parc.xerox.com>
  10. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  11. Subject: Re: [URN] a possible security architecture for URNs
  12. In-Reply-To: <96Oct16.141925pdt."2764"@golden.parc.xerox.com>
  13. References: <2.2.32.19961015164822.006c4494@acl.lanl.gov>
  14.     <96Oct16.141925pdt."2764"@golden.parc.xerox.com>
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Larry Masinter writes:
  21.  > > Linked local name spaces. SDSI does not utilize a global name
  22.  > > space,
  23.  
  24. Don't be fooled by that statement.  They do utilize a global name
  25. space, as they later admit.
  26.  
  27.  > With this background, we come to the part that I think represents a
  28.  > viable URN framework for uniform universal names that can be
  29.  > implemented in a distributed resolution framework with adequate
  30.  > security:
  31.  > 
  32.  > > Accomodation for ``standard roots'' and global name spaces: We recognize
  33.  > > that there are likely to be a set of standard ``special root'' principals
  34.  > > that are ``universally'' recognized. These principals have SDSI reserved
  35.  > > names ending with double exclamation marks (!!):
  36.  > 
  37.  > >        VeriSign!!
  38.  > >        IAPR!!
  39.  > >        USPS!!
  40.  > >        DNS!!
  41.  > 
  42.  > > There will be very few of these special roots, and their names
  43.  > > are bound to the same principal in every name space.
  44.  
  45. That's the only way to get a global name space with the same meaning
  46. for everyone, as I have been arguing all along.
  47.  
  48.  > > This is
  49.  > > arranged with suitable procedures (appropriate publicity, manual
  50.  > > installation, cross-checking, etc.); we do not try to describe
  51.  > > this in more detail. This gives SDSI access to ``standard'' name
  52.  > > spaces:
  53.  > 
  54.  > >        VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith
  55.  > >        DNS!!'s edu's mit's lcs's theory's Silvio-Micali
  56.  > >        USPS!!'s USA's DOD's DCI
  57.  > >        IAPR!!'s PCA-commerce's DEC's SRC's abadi
  58.  > >        VeriSign!!'s Visa's account-234156742
  59.  > 
  60.  > > Each of these should be viewed as global names that evaluates to
  61.  > > the same principal in every name space, since the first name
  62.  > > (e.g. VeriSign!!) always evaluates to the same principal, and all
  63.  > > of the subsequent names are relative.
  64.  > 
  65.  > > Although SDSI provides for special roots within a set of linked
  66.  > > name spaces, this does not imply that each principal has a unique
  67.  > > ``global name.'' A principal will have multiple global names if
  68.  > > there are multiple paths from special roots to that
  69.  > > principal. Thus,
  70.  > 
  71.  > >         VeriSign!!'s MicroSoft's CEO
  72.  > >         DNS!!'s com's microsoft's "Bill Gates"
  73.  > 
  74.  > > may refer to the same principal. (Of course, one can check
  75.  > > whether these two names evaluate to give the same public key, if
  76.  > > one wishes.)
  77.  
  78. This is all fine.  But how is it any different architecturally from
  79. the path scheme and the NAPTR scheme?  All are hierarchical, and
  80. within each nested name space, local names can be defined to map
  81. to another name space.  So we could use
  82.  
  83.   path:/DNS!!/com/microsoft/"Bill Gates"
  84.  
  85. The NAPTR scheme is much the same with a different notation and
  86. resolution mechanism.
  87.  
  88.  > I hope this clarifies what I was asking people to "check out", namely:
  89.  > a system of hierarchical naming where the issues of identity and
  90.  > authority have been actually thought out.
  91.  
  92. I don't see how they have thought it out any more than we have.
  93. What are we missing?
  94.  
  95. --
  96. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  97. National Center for Supercomputing Applications
  98. http://union.ncsa.uiuc.edu/~liberte/
  99.